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REMARKS 

I. Summary of the Office Action 

Claims 1-24 are pending in this application. 
Claims 25-54 are cancelled. 

Claims 1-2, 4, 7-17, 19 and 21-23 were rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Belknap et al., U.S. Patent No. 5,586,264 ("Belknap") and 
RealNetworks, in view of "RealSystem G2 Production Guide," 
http://service.real.com/help/library/guides/productiong27/realpgd.htm ("Real"). 

Claims 3, 5-6, 11, 18, 20 and 24 were rejected under 35 U.S.C. § 103(a) as 
being unpatentable over both Belknap and Real as applied to claims 1 and 17, and 
further in view of RealNetworks, "RealServer Administration Guide," 
http://service.real.com/help/library/guides/g270/realsrvr.htm ("Administration"). 

II. Summary of Applicants' Response 

Applicants respectfully request that the Examiner consider the proposed 
amendments to claims 1,17 and 24. The proposed amendments to claims 1,17 and 24 
more clearly point out and distinctly claim the subject matter of the present invention. 

With respect to all amendments and cancelled claims, applicants have not 
dedicated or abandoned any unclaimed subject matter. Applicants reserve the right to 
pursue prosecution of any presently excluded claim embodiments in future continuation 
and/or divisional applications. 

Applicants respectfully traverse the claim rejections under 35 U.S.C. § 103(a). 

III. Response to Claim Rejections Under 35 U.S.C. § 103(a) 

Applicants respectfully submit that the combination of Belknap, Real, and 
Administration fails to render obvious the claimed invention. Applicants respectfully 
submit that there is no suggestion or motivation to combine the references, and even if 
there were, the combined references do not teach all of the claim limitations. 

In particular, the combined references do not teach the claim limitation that "all 
media assets within an asset group sharing storage medium bandwidth and storage 
space on the server computer that is reserved for the asset group for guaranteeing a 
specified number of simultaneous playouts for each media asset within the asset group" 
(claim 1). 
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As the Examiner recognizes in the Office Action, "Belknap fails to teach a file 
system organized into a plurality of asset groups, each asset group comprising at least 
one media, and the media asset sharing storage medium bandwidth and storage space 
on the server computer that is reserved for the asset group to which the media asset 
belongs" (Office Action, paragraph 3, pages 2-3). 

The Examiner has suggested that "Real discloses a file system organized into a 
plurality of asset groups, each asset group comprising at least one media asset, and the 
media asset sharing storage medium bandwidth and storage space on the server 
computer that is reserved for the asset group to which the media asset belongs" (Office 
Action, paragraph 3, page 3). The Examiner has further suggested that "it would have 
been obvious to one having ordinary skill in the art at the time of the invention was 
made to modify Belknap in view of Real organized at least one media asset into a 
plurality of asset groups and sharing bandwidth and storage space based on the media 
asset because this feature lowers bandwidth consumption. One of ordinary skill in the 
art at the time of application's invention would have been motivated to modify Belknap 
in view of Real in order to stream a certain number of simultaneous media assets at any 
time" (Office Action, paragraph 3, page 3). 

Applicants respectfully submit that, contrary to the Examiner's suggestion that 
"Real discloses assets are organized in a group based on the connection speed" (Office 
Action, paragraph 26, page 13), Real does not disclose asset groups as taught by the 
present invention; rather, Real at most simply discloses "options each RealPlayer can 
choose based on its available bandwidth" (chapter 7, page 94) to serve different clips to 
viewers with different connection speeds. 

The Examiner's interpretation of Real as disclosing that media assets are 
organized in asset groups as taught by the present invention is incorrect. The SMIL 
body of code that the Examiner points out as disclosing this feature (described in Real 
at chapter 7, pages 94-95) shows that clips are placed in a group according to the 
"approximate bandwidth (in Kbps) each group consumes," such as a group "for dual 
isdn and faster" at "75000" Kbps, a group "for single isdn" at "47000" Kbps, and a 
group "for 28.8 modems" at "20000" Kbps. The body of code only shows one media 
asset per connection speed, e.g., "newsongl.rm" for 75000 Kbps, "newsong2.rm" for 
47000, and "newsong3.rm" for 20000. There is no indication, suggestion, or teaching 
in Real that if more than one media asset were placed under a group for a given 
connection speed that those assets would be "sharing storage medium bandwidth and 
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storage space on the server computer that is reserved for the asset group for 
guaranteeing a specified number of simultaneous playouts for each media asset within 
the asset group" (claim 1). 

In Real, media assets are organized according to their connection speed "to 
serve different clips to viewers with different connection speeds" (Real, chapter 7, page 
94). There is no suggestion or teaching in Real that clips under a given connection 
speed would be "sharing storage medium bandwidth and storage space on the server 
computer that is reserved" (claim 1) for the assets under the given connection speed. 
Real only shows one clip under each given connection speed. In that case, the one clip 
is not sharing storage medium bandwidth with any other clip as there is no other clip in 
the grouping under a given connection speed. And even if more than one clip were 
placed under a given connection speed, there would still be no suggestion or teaching in 
Real that those clips would be sharing storage medium bandwidth for that particular 
grouping. 

The Examiner has recognized that "Real does not use the exact term 'sharing'" 
(Office Action, paragraph 26, page 13). The Examiner's suggestion that "when assets 
are organized in a group based on the connection speed, then it may be sharing 
bandwidth for playing out assets" (Office Action, paragraph 26, page 13) is nowhere 
disclosed in Real, nor would it be obvious to one of ordinary skill in the art to believe 
so. 

As set forth in the proposed claim 1, all media assets in a given asset group 
share storage medium bandwidth and storage space for "guaranteeing a specified 
number of simultaneous playouts for each media asset within the asset group." There is 
no teaching in Real that media assets grouped under a given connection speed would 
have a guaranteed number of simultaneous playouts. The guarantee of a specified 
number of simultaneous playouts is provided "to reserve storage bandwidth" 
(specification, page 1, line 11), which "refers to the transmission bandwidth available 
for transfer of media assets stored on the server computer over a communication 
medium, such as a network connection. For example, the storage bandwidth for one 
media asset doubles when two media assets of the same size are played out 
simultaneously" (specification, pagel, line 13, to page 2, line 4). 

In an example provided in the specification with reference to FIG. 1, if "a user 
desires a maximum of ten playouts from a set of ten 1 Mbps assets, each of which 
occupies ten MB of storage space" (specification, page 2, lines 15-17), "typical 
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implementations install each of these assets with ten guaranteed playouts. If these 
assets are all placed on a single file system with a bandwidth capacity of 100 Mbps and 
space capacity of 1 GB, then the entire file system bandwidth is consumed and the file 
system is no longer usable for further asset installations even though only 100 MB of 
disk space has been used. This is wasteful in terms of file system bandwidth and 
space" (specification, page 2, lines 19-24). 

"Directing attention to FIG. 2, the present invention avoids the shortcomings of 
the problems discussed above and illustrated in FIG. 1 by organizing media assets into 
asset groups" (specification, page 4, lines 13-14), which are "a set of media assets 
(static image, video, audio, text, or combinations thereof) that can be played on a 
computer and which share a certain amount of system resources, such as storage space 
and storage bandwidth. FIG. 2 illustrates the manner in which asset groups can be used 
so that the storage bandwidth on the conventional system and method of FIG. 1" 
(specification, page 4, lines 15-20). 

Accordingly, an asset group as taught by the present invention stores media 
assets in such a way that the storage bandwidth is shared by all assets within the asset 
group. An asset group does not encompass a simple grouping or listing of media assets 
under a given connection speed without any further attributes as disclosed in Real. An 
asset group according to the present invention requires that assets stored therein share 
storage bandwidth, as shown in FIG. 2. There is no indication in Real that media assets 
stored under a given connection speed would be sharing storage bandwidth as taught by 
the present invention. 

Furthermore, Real does not even teach how media assets under a given 
connection speed would be stored in a server computer, let alone how they would be 
stored to share storage bandwidth. It would not be obvious to one of ordinary skill in 
the art that the media assets listed under different connection speeds in Real would be 
stored in such a way so as to share storage bandwidth for each connection speed. One 
of ordinary skill in the art would not be able to draw any conclusions as to how the 
media assets under each connection speed are stored in a server computer based on the 
body of code provided in Real at chapter 7, pages 94-95. The body of code only shows 
one media asset under each connection speed, without any indication that more media 
assets could be listed under each connection speed and without any indication that they 
could be stored to share storage medium bandwidth. 
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As claimed in claim 1, sharing of storage medium bandwidth guarantees u a 
specified number of simultaneous playouts for each media asset within the asset 
group." Such guarantee is not provided in Real, nor would it be obvious to one of 
ordinary skill in the art that such guarantee can be provided based on the body of code 
shown in Real at chapter 7, pages 94-95. The Examiner has even recognized that "both 
Belknap and Real fail to teach the asset group is associated with a guaranteed possible 
playouts value that guarantees the number of playouts from each asset" (Office Action, 
paragraph 19, page 8). 

Applicants respectfully submit that the Examiner's suggestion that 
Administration discloses options and parameters that system administrators of a 
"RealServer" can specify to guarantee the number of playouts from each asset is 
incorrect. Those options and parameters include "MaximumClientConnections," 
indicating "the number of clients who connect simultaneously" (Administration, 
chapter 14, page 210) and "MaximumBandwidth," indicating "the amount of 
bandwidth RealServer can use to any number of kilobits per second (Kbps)" 
(Administration, chapter 14, page 210). 

As the Administration disclosure describes, those parameters pertain to a single 
RealServer where all the media assets are stored. There is no suggestion in 
Administration that the media assets stored in the RealServer should be stored in the 
RealServer so that they "share storage medium bandwidth and storage space" (claim 1) 
on the server. Moreover, the "MaximumClientConnections" and 

"MaximumBandwidth" parameters provide no guarantee of "a specified number of 
simultaneous playouts for each media asset within the asset group" (claim 1). They 
simply provide, as described above, "the number of clients who connect 
simultaneously" (Administration, chapter 14, page 210) and "the amount of bandwidth 
RealServer can use to any number of kilobits per second (Kbps)," and not "a specified 
number of simultaneous playouts for each media asset within the asset group" (claim 
1). 

In short, the combination of Belknap, Real, and Administration does not teach 
the claimed limitation of "all media assets within an asset group sharing storage 
medium bandwidth and storage space on the server computer that is reserved for the 
asset group for guaranteeing a specified number of simultaneous playouts for each 
media asset within the asset group" (claim 1). 
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Applicants therefore respectfully submit that the combination of Belknap, Real, 
and Administration does not render the claimed invention obvious. Accordingly, 
applicants respectfully submit that claims 1-24 distinguish from, and are allowable 
over, the cited references. 

Applicants further submit that none of the tertiary references cited in the Office 
action remedy the deficiencies in the combination of Belknap, Real, and Administration 
and thus cannot render the claimed invention obvious. 
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CONCLUSION 



In view of the above amendments and remarks, applicants respectfully submit 
that the present application is in condition for allowance. 

If any matters can be resolved by telephone, the Examiner is invited to call the 
undersigned at the telephone number listed below. 

While Applicant believes that no further fees are due at this time, the 
Commissioner is authorized to charge any fees that may be due as a result of filing this 
amendment, including additional claims fees not already paid for, extension fees or 
other fees that have not been separately paid, to Deposit Account 50-2319 (Order No. 
A-69479/RMA/MRC (Our File No. 468914-22)). 



Customer No. 32940 

DORSEY & WHITNEY LLP 
555 California Street, Suite 1000 
San Francisco, CA 94104-1513 
Telephone: (650)587-1717 
Facsimile: (650)587-1288 



Respectfully submitted, 



Date: November 2 L 2005 




R. Michael Ananian 



4816-3420-4928V2 
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